The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Computer network infrastructure devices such as routers and switches store values for many types of state variables as part of normal operation. The state variables may include numerous types of counters, such as packet loss counters. Network administrators typically examine discrete values of the state variables at a particular point in time, also termed obtaining a “snapshot” of a state variable value, when a device is experiencing problems and when the current performance status of the device is reviewed.
However, such a snapshot may not provide a complete picture of performance issues associated with the device. Specifically, a snapshot value does not convey the trend and the tendency of a particular state variable—that is, is the value of the state variable getting better or getting worse? Is the trend accelerating or decelerating? Answers to these questions are important to assess a proper course of action.
Determining a trend and a tendency for a state variable requires observation of the device and the state variable over time. Thus, one approach to assess a trend and a tendency of a state variable is for a management station or network administrator to repeatedly poll the device to request a different snapshot of the state variable at successive times. However, such a repetitive polling of counters and state variables imposes a large strain on the performance of management applications, uses excessive processing resources of managed devices, does not scale well in networks that have thousands of devices, and introduces a dependency on expensive management applications to determine trend and tendency values.
Further, devices often do not store historical values for the state variables; therefore, the needed information may be unavailable when a snapshot is taken. Even if historical information were present in a device, determination of trends based on the historical information would require additional computation power and analysis logic in management applications.
Based on the foregoing, there is a clear need for a way to obtain trend and tendency information for state variables in network devices, without incurring the overhead of continuous monitoring or repetitive polling.
Some management information bases (MIBs) define notifications that can be emitted in case certain events are occurring, including events related to performance variations. An example is the Remote Network MONitoring (RMON) MIB, in which setting a notification variable causes the system to deliver notifications about changes in RMON values. The use of such notifications requires the presence of a powerful management application integrating diagnosis and event processing. Coverage of those notifications is generally incomplete. Furthermore, notifications do not address the problem of providing information on-demand at arbitrary points in time.
Certain management applications provide trending over past statistical data, but obtaining such trending requires data to be collected from the application over some period of time and to be computed by the application, not the device. Further, a trend indication of an alarm state may be communicated through an alarm (e.g., an alarm may include a state value of “severity major, deteriorating” after a previous severity had been “minor”). However, such alarm information refers to alarm state, not to a general statistical counter, and is not something that can be retrieved on demand.
The NetFlow application that is integrated into Cisco IOS® Software from Cisco Systems, Inc., San Jose, Calif., maintains a statistics database on the device including certain historical data and provides summation functions. However, the NetFlow service can report historical data only on flow data available through NetFlow, not any state variable represented by any MIB in a device. Further, NetFlow cannot deliver trend and tendency data for a particular state variable to an application on demand; instead, applications are continuously exposed to a flow of data from the device. The summary functions of NetFlow, which aggregate data from multiple flows, are different from trend and tendency functions, which mathematically convey the first and second deviation of the function of the state variable over time (x axis time, y axis value of the state).
Other network device features such as RMON and PDM/PIX offer a capability to collect and maintain certain statistics on a device, for instance the snapshot of certain statistical parameters at certain time intervals, but not trend and tendency information. For example, RMON provides a History Control Group that allows values representing a history of various network media to be kept on an RMON agent on a network device; however, there is no computation of trend or tendency. RMON provides a User History feature that allows values representing history to be stored on the device; there is no computation of trend or tendency.
The Cisco PIX Firewall allows certain statistics values to be collected and maintained, including interface statistics, feature statistics, failover statistics, connection performance statistics, DHCP statistics, etc., and displayed as graphs in PDM, an application hosted outside the device. A user or management application can determine a trend or tendency only through further manipulation of the information and only outside the device; the firewall or device do not internally compute and cannot deliver trend and tendency immediately upon demand.